1. Technical Field
The invention relates to view management. More particularly, the invention relates to graphical user interfaces that provide multiple views of related information.
2. Description of the Prior Art
Graphical user interfaces that provide multiple views of related information (such as frames, panes, or windows) are becoming increasingly prevalent in commercially available software products. Unfortunately, current multi-view interfaces are severely limited by a lack of user level control over the relationships between views, view placement and layout, and view presentation.
Most contemporary windowing systems employ an independent, overlapping windowing model (see, for example, E. Kandogan, B. Shneiderman, Elastic Windows: Evaluation of Multi-Window Operations, ACM Conference on Human Factors in Computing Systems SIGCHI 97 (March 1997)). As graphical user interfaces become increasingly information intensive, individual applications within these windowing systems have grown to provide multiple related views of information. These related views are typically ad hoc in their interaction and functionality, i.e. there is little user level control over the relationships between views, view placement and layout, and view presentation.
It is becoming more commonplace for application programs to use multiple linked views to visualize large amounts of content. However, current implementations of these information intensive interfaces give users virtually no control over where a followed link is displayed. Users need ways to arrange and link windows that suit their own tasks. In fact, many users have strongly differing opinions over various approaches to view management. These are quasi-religious arguments for which there are no universally correct answers. While some people prefer multi-paned windows, stacked vertically or horizontally, others despise the paned approach and choose to use separate windows. This diversity of opinions argues for maximum flexibility, allowing users to customize the way in which their views are managed.
The following discussion illustrates these issues through three sample applications, i.e. Netscape Navigator, Netscape Messenger, and filesystem browsers in the Windows 95 and Macintosh operating systems.
Netscape Navigator.
Netscape Navigator's default behavior is to follow a link by replacing the current browser context. The Web page author can change this default behavior on a link-by-link basis. For example, HTML-based frames can be created and targeted programmatically by writing HTML or Javascript code. However, the user has no way to change the preprogrammed targeting. This statically defined "one-size-fits-all" behavior may be frustrating and problematic in some common browsing scenarios.
An example of the foregoing involves browsing the set of results returned by a search engine such as Alta Vista. Users typically want to explore several promising sites listed in the page of search results. The typical interaction is to follow a link, look at the page, and then hit the back button to redisplay the search results. There are several problems with this ping-pong approach. First, the user loses context because the search results and followed link are not visible at the same time. Second, the constant switching of contexts requires extra navigation steps.
Another common interaction technique is to right-mouse on the link, and choose open in new window from the context menu. This causes the link to expand in a new window. The problem with this spawning approach is that a large number of temporary windows are explicitly opened and used only briefly before being closed. In addition, a cumbersome pop-up menu must be used for each link traversal.
Neither of these approaches is ideal. The user often wants to use the page of search results as a persistent launcher that opens the links in another specified view. In fact, this approach is so compelling that it is often hard coded into sites that use multiple frames. Unfortunately, few sites expend the effort required to implement this behavior, and users are still unable to customize which view (i.e. frame or window) is used to display the followed link.
News and Discussion Browsers.
A related problem is the navigation of highly structured Web content. Examples include HTML-based email, such as hotmail, and newsgroup-like HTML message boards, such as those found at the popular financial discussion site Silicon Investor. When viewing these structured discussions, there are at least two levels of Web page structure above the message that make standard Web navigation techniques suboptimal.
For example, at the Silicon Investor site, users must navigate between a list of active bulletin boards, a list of subject headers for each board, and the actual message contents. Once again, the ping-pong and spawning approaches discussed in the previous section are inadequate, and the problem is exacerbated by the need to manage a larger number of related contexts.
FIGS. 1(a)-(c) depict a small number of boards and their content from Silicon Investor. There are five discussion areas (FIG. 1(a)), each containing an average of nine mail messages (FIG. 1(b)) to be browsed and read (FIG. 1(c)), for a total of 51 web pages (one discussion listing+five lists of messages+45 messages).
Using the spawning approach, a separate window is needed for each visited page, for a total of 51 windows and 50 link traversals. In addition, because this link following method is not a default single-click operation, the user must access the context menu 50 times to create the windows, and explicitly close each of the 50 new windows to complete the task. This results in a total of 51 windows and 92 user actions. Using the ping-pong approach, only one window is needed, but the back button must be pressed 50 times to traverse all of the messages, for a total of 101 views and 101 user actions. The inherent multi-level structure of discussion groups make both the ping-pong and the spawning approaches cumbersome for the user.
Clearly neither of these approaches constitutes efficient view traversal (see G. Furnas, Effective View Navigation, ACM Conference on Human Factors in Computing Systems SIGCHI 97 (March 1997)). One way to improve the browsing of structured messages such as these is to provide a dedicated view for each of the three levels of structure. Netscape Communicator's special purpose discussion group browser that does just that. The browser provides three related views to manage discussions, as shown in FIG. 2(a).
A list of discussion groups appears in a separate window called the message center. The threads and message content can be stacked under each other or displayed in their own windows. This preference is set via a disclosure triangle on the thread window, as depicted in FIG. 2(b). By default, these three related views of discussions are linked, but as FIG. 2(c) shows, users can alternatively choose to always spawn separate windows for threads or mail message content.
Thus, in FIG. 2(a), which shows the Netscape Communicator News Browser, the message center is always a separate window. The arrows indicate link relationships. Selecting a mailbox in view 1 expands into the mailbox in view 2. Selecting a message in view 2 causes the message contents to appear in view 3. FIG. 2(b) is a closeup of the Netscape Messenger mail pane control. Clicking on the triangle creates a separate window for viewing the contents of mail or news messages. FIG. 2(c) shows Netscape Messenger targeting preferences. Users can only choose between two targeting options in the primary mail and news windows, as discussed above.
The news browser provided in Communicator is more flexible than most browsers, and is adequate for many users. However, there are some limitations. First, some useful linked layouts cannot be specified. The most notable omissions are a trio of three-paned layouts shown in FIGS. 3(a)-3(c). The layout of multiple message views is often an important user issue, so it is disconcerting when users cannot use a preferred layout.
Another problem is inconsistent link traversal behavior. Following links to separate windows require a double click; links within the same window are a single click. This inconsistency detracts from the usability of the system. Users expect the same single or double click behavior regardless of the windowing approach.
Filesystem Browsers.
Web pages and news readers are not the only applications that concern highly structured information. Traditional filesystem browsers display multiple levels of hierarchically structured information about the computer's local file system. Hard disks contain folders, and each folder contains files, applications, and yet more folders for multiple levels. The user may want to browse different parts or levels of this structure, or compare two or more parts at once. Traditional file system browsers provide little support for these tasks, and the support they do provide is very inconsistent and ad hoc.
FIG. 4 shows Macintosh Finder windows, where the dashed arrow indicates an expanding link with no ongoing relation between the views. There is no way to coordinate multiple windows containing related information in the Macintosh Finder.
The Macintosh Finder, shown in FIG. 4, has no capabilities for multi-view browsing. The Finder's windows are each controlled independently and limited to a single view. There is no way to coordinate multiple windows containing related information. If users want to browse the contents of the system folder quickly, they must either double-click on each folder to spawn off a new window, or use a single window and manipulate the inline disclosure triangles to expose and hide nested levels of structure. The first spawning approach has the same drawbacks as spawning in the Web browsing example discussed above. The disclosure triangle approach is effective for small hierarchies, but quickly becomes unwieldy when there are many objects and the view must be scrolled.
Windows95/NT has more options than the Macintosh, but it is difficult to switch between approaches. In Windows, the user has a choice of three schemes for browsing files, i.e. reuse a single window (as with a Web browser), spawn a new window (as with the Macintosh Finder), or use a special browser called the Explorer. By default, the windowing system employs the reuse approach. When a user double clicks on a folder, the window's contents are replaced with the contents of the selected folder. The user can press the backspace key to move up one level to the folder containing the current folder. This approach is virtually identical to the Web reuse window approach described above and therefore has the same limitations.
Alternatively, the Windows95/NT user can cause folders to expand in multiple independent windows by holding down a modifier key or changing a global preference. This spawning approach is similar to that of the Macintosh Finder and has the same spawning drawbacks discussed above.
The third option is the Windows97 Explorer, as shown in FIG. 5. The view on the left shows only the folders or structure of the file system. Selecting a folder on the left displays its contents on the right. The user is presented with a two-view browser onto the file system, as shown in FIG. 5. This browser shows the folders on the hard disk in the left pane. The entire contents of whichever folder is selected are displayed expanded in the right pane. The two panes are always split left-right with no option for the user to customize the layout. In addition, there is no way to spawn a new Explorer window when browsing in an Explorer window. Even creating a separate, unrelated, old style browsing window is cumbersome, requiring the use of a context menu.
The above examples illustrate the limitations of static linking and show why it impedes browsing. What is needed is a way to link together and manipulate views, and specify layouts of views, dynamically. It would therefore be advantageous to provide users with a mechanism for to expressing and controlling view management issues.